Migrating away from Stripe Billing is not just a technical project. It is a customer continuity project. And the difference between those two framings is where most migrations go wrong.
Here is the thing most teams discover too late: Stripe is not just a payment processor in your stack. Over time it becomes the place where customer identity, subscription state, trial logic, invoice history, billing cycles, payment methods, and lifecycle events all quietly live. When you decide to move, you are not moving a billing system. You are moving your customers' relationship with your product.
That is a very different problem to solve.
This is where a lot of migration plans fall apart before they even start. Teams assume Stripe will hand over everything neatly. The reality is more nuanced, and knowing exactly what you are working with changes how you plan.
Here is what Stripe provides, and how.
What comes from the PAN export (via Stripe's migration team)
When you formally request a data export from Stripe to move to another processor, Stripe prepares an encrypted JSON file and arranges a secure transfer directly to your new processor. This is a manual process that requires coordinating with Stripe's migration team, and it only works if your new processor is PCI DSS Level 1 compliant.
What that export contains:
cus_...)What it does not contain:
Those are not part of the PAN export at all. Stripe explicitly states that payment history, subscriptions, and other non-PCI data are not included in the export file. You retrieve those separately through the API or the Stripe Dashboard, and you can continue to access them for as long as you keep your Stripe account open.
What you retrieve yourself via the API
Through Stripe's API, you can export everything else. The subscription object gives you a lot to work with:
Invoice history is retrievable per customer through the API with full line items, amounts, tax, status, and payment intent references. Payment method details such as the card fingerprint and last four digits are accessible on the customer object. The full card number is only available through the PAN export process described above.
What is genuinely missing
The gaps worth planning around are:
Even knowing exactly what Stripe provides, most engineering teams still approach this as a data migration. Export, import, flip the switch. Job done.
The problem is that the data is only part of it. What a subscription really represents is a promise to the customer: your access continues, your renewal happens when you expect it, your saved payment method works. That promise lives across billing state, entitlement state, and product state simultaneously. Moving the billing record does not automatically move all three.
Miss any of them and the customer notices. Their access breaks mid-cycle. Their invoice history disappears from the support tool. Their next payment hits at the wrong time because the billing cycle anchor did not transfer correctly. Or they get two dunning emails because both systems try to recover a failed payment at once.
None of that is the customer's problem. But they feel all of it.
To be fair to Stripe, it is genuinely excellent at what it was built for. Recurring payments, invoices, subscription charging, usage tracking. If you are web-only and Stripe-centric, it does the job really well.
But at some point, a lot of subscription businesses start needing things that live outside that scope:
This is where the billing-centric architecture starts to feel limiting. Not because Stripe is bad, but because the business has grown into a different kind of problem. Billing execution is still needed. But subscription orchestration is what is actually missing.
The instinct to do a big-bang migration is understandable. It feels clean. But it is the fastest way to break something for a customer at the worst possible moment, usually right at renewal.
The safer model is staged. It goes roughly like this.
Start by mirroring, not moving.
Pull your Stripe customers, subscriptions, products, prices, invoices, and discounts through the API. Store the Stripe customer ID, the external ID from metadata that maps to your own database, the subscription ID, the price ID, and all the relevant lifecycle state. Bring this into Azotte as mirrored records.
At this stage, Azotte is not charging anyone. It is reconstructing the subscription truth: who each customer is, what they are entitled to, what they currently pay, when their next renewal should happen, and what rules apply to their lifecycle.
Stripe keeps running exactly as before. Nothing changes for the customer yet.
Keep listening to Stripe while you prepare.
This part is easy to forget. Customers do not pause their lives while you migrate. Payments fail, trials end, upgrades happen, cancellations come in. All of that keeps flowing through Stripe's webhooks right up until you cut over. Your migration system needs to stay in sync with those events, or you will start the new platform with stale state on day one.
Separate entitlement migration from payment migration.
This is probably the most important decision in the whole process. Customer access should not depend on the payment migration being finished.
Azotte can become the entitlement and lifecycle control plane first, while Stripe continues collecting payments during the transition. In practice that means:
This way the customer never experiences a sudden shift in billing behaviour. The transition happens quietly underneath.
Never throw away Stripe IDs.
Every migrated record should permanently keep its original Stripe references: the cus_ customer ID, the subscription ID, the price ID, the invoice ID, the payment method fingerprint, and any external IDs you stored in metadata. This is not just tidy housekeeping. It is how customer support, reconciliation, refund processing, audit checks, and rollback procedures stay functional. A migration without clean ID mapping becomes very painful very quickly.
Plan for card re-authorisation before you need it.
The PAN export gives you the card details you need to tokenise payment methods on the new processor. But there is a window between when the export was taken and when the migration completes, during which some customers may have updated their payment method in Stripe. Those changes will not be in the export. You need a fallback flow ready for customers who land in the new system without a valid payment method on file, ideally a clean prompt to re-enter their card that does not feel alarming.
Link users are a separate case. Those payment credentials cannot be exported at all and will need to be handled proactively.
Migrate in cohorts, not one global switch.
Group customers by risk profile and complexity before moving them:
Before moving each cohort to the next stage, validate that everything matches: renewal date, billing cycle anchor, entitlement state, price and currency, discount logic, invoice expectations, access state, and what the next billing action should be. If anything does not line up, stop and investigate before continuing.
This is one of the easiest places to quietly lose customers during a migration, and it is easy to underestimate.
Customers in a failed payment state are not normal active subscribers. They are mid-recovery. They might be in a grace period. They might be waiting on an SCA authentication step. They might have already been contacted once by Stripe's dunning logic.
If they get pulled into the new platform's standard flow without handling this carefully, they can end up receiving duplicate dunning messages, losing access at the wrong moment, or getting charged twice. None of those outcomes are recoverable without a support interaction.
These customers need a specific path: clear access rules during the transition, preserved grace periods, no duplicate payment attempts, and a clean handoff into Azotte's recovery flows once the migration is complete.
After a successful migration, Azotte should be the single orchestration layer for subscription lifecycle, entitlement state, plan and package mapping, trials and eligibility, family sharing, referral rewards, winback campaigns, payment routing, storefront rules, and customer support visibility.
Stripe can absolutely stay in the stack as a payment processor if that makes sense. The key change is that Stripe is no longer the place where subscription truth lives. It handles payments. Azotte handles everything else.
A migration that goes well is almost invisible to the people it affects most.
Customers should not need to re-register. They should not lose access during the switch. They should not receive confusing invoices or experience unexpected payment timing. The only customers who should hear from you directly are those who genuinely need to do something, like re-entering their card details or completing an SCA step.
For everyone else, the message is simple: your subscription continues as usual, your access and renewal date are unchanged, nothing you need to do.
Behind that simple message is a lot of careful orchestration. But that is the whole point. The customer should never see it.
Migrating from Stripe Billing is really about recognising that billing-centric architecture has a ceiling. It works well up to a point. Then the business grows beyond what a billing tool was designed to carry.
The goal is not to find a better billing system. The goal is to move from payment-led subscriptions to orchestration-led subscriptions, where the billing engine is one component of a broader system rather than the system itself.
That shift is what makes the next phase of growth actually manageable.
If you are planning a migration or already in the middle of one and hitting unexpected complexity, Azotte was built around exactly this problem. Worth a look.